Specifying Finite-State Actors

Programmers often code up asynchronous message-passing systems as communicating finite-state actors. An actor in some state listens for messages, responds to those messages, and transitions to another state. Most of these systems allow messages to carry actor addresses. This paper presents a kernel language for implementing and specifying such systems. A specification consists of finite-state machines, expressing what kind of messages each component should expect and what kind of actions it should take in response. In addition, a specification may prescribe how a component may use an address received from a message as well as how a component handles inputs on addresses that it sends out. Finally, the paper adds a conformance relation that articulates when an implementation meets such a specification. 1 Communicating FSM Actors When programmers work on concurrent systems, many reach for Hewittstyle actor [1] frameworks such as Akka [2] and Erlang [3]. In addition, programmers often organize actors as state machines that, in any given state, listen for messages, and when messages arrive, process them and transition to another state. A basic notion of correctness for such actor systems must be formulated in terms of a protocol from the perspective of individual actors. Therefore, a specification framework must focus on descriptions of an actor’s actions in response to messages. For example, in a telephony system, an actor managing a telephone may be responsible for ensuring that – every new call request receives an accept or reject response, – during a call, every incoming call is rejected, and – hanging up the receiver terminates the call. Smith and Talcott’s specification diagrams (SD) [22] provide a completely general setting for specifying all kinds of actors. SD supports both graphical and textual forms of specification. Its specifications view actor ? This is an extended version of a paper presented at WSFM/BEAT 2015. systems as non-deterministic compositions, with mathematical expressions serving as constraints. The very expressiveness and generality of SD makes it difficult, however, to prove conformance between specifications and programs. Indeed, Smith and Talcott focus on refinements among specifications alone, though one could extend this notion to programs. To specify actor protocols that admit tractable conformance proofs, our approach is to focus on the widely used finite-state organization of actors and to exploit this structure. Our contributions are 1. a language of communicating FSM actors, which distills the essence of implementing FSMs in Akka and Erlang into a small model; 2. a specification language for protocols in this setting, and 3. a conformance relation between specifications and programs. We then add a conformance proof for an actor protocol akin to Akka’s interface to TCP. The paper is organized as follows. Section 2 motivates the problem with an example from the world of network protocols. Section 3 then introduces the programming language and sketches how to implement the protocol example from section 2 via actors. The heart of the paper— sections 4 through 6—presents the specification language, a conformance relation between specifications and implementations, and a conformance proof sketch (appendix A contains the full proof). Sections 7 and 8 round off the paper with related and future work. 2 The Alternating Bit Transport Protocol Our running example is an implementation of a hypothetical protocol, called the Alternating Bit Transport Protocol (ABTP). At the application level, ABTP mimics the interface of the Akka TCP implementation as a representative of typical patterns in actor programs. At the network level, ABTP combines TCP and the Alternating Bit Protocol [5]. Using ABTP, a sender program on one network host can reliably transmit a sequence of messages to some existing receiver program on a different host over unreliable network links. As in the Alternating Bit Protocol, ABTP achieves this reliability by repeatedly transmitting one message at a time until it receives a matching acknowledgment. Two-way handshakes establish and close a connection. The ABTP Session Lifecycle Figure 1 illustrates one possible message sequence of this protocol. The manager is the entry point process on